1. Field of the Invention
The present invention is directed toward the field of object oriented development environments, and more particularly to integrating foreign objects and different data sources into a single integrated object oriented environment.
2. Art Background
An object oriented approach to programming provides many advantages over traditional procedural programming approaches. For example, an object oriented approach permits code reuse through inheritance and modularity through encapsulation. There are many views as to what concepts define object oriented programming, and there are many terms and definitions for defining these concepts. In general, objects incorporate procedures, also called methods or operations, and data, also called attributes or properties. Objects are instantiated from and described by structures known as classes or types. For purposes of nomenclature, the object oriented programming environment described herein defines classes as types. A type is a general abstract specification, and an object instantiated from a type is a specific concrete instance of the type.
A type consists of an interface and an implementation. The interface comprises variables and function declarations, wherein the variables represent the attributes of the type, and the function declarations specify methods for manipulating those attributes as well as performing other operations. The declaration specifies the name, return type, and argument, known collectively as the signature. The implementation refers to the actual code that implements the methods specified in the interface. Types may consist of abstract types or implementation types. Objects are not instantiated from abstract types. Instead, objects are instantiated from an implementation type.
Object oriented languages, such as the C++ language, permit the creation of special types via inheritance. In general, inheritance is a mechanism for passing attributes and methods from a parent or base type to one or more child or derived types. Inheritance permits code reuse because interfaces and implementations need not be duplicated in the child type. Instead, the interfaces and implementations may be incorporated in any child type through reference of the parent or base type.
In general, objects communicate through message passing mechanisms. An object, known as a client object, may call a method of another object. A client object invokes a method of another object by accessing the object via the defined interfaces. Thus, to invoke a method in an object or to query an object, the client object requires knowledge of the signatures of the methods in the interface of the target object. The client object calls the methods and passes the appropriate parameters. For example, to obtain the value of an attribute in an object, a client object calls a method, via an interface, to obtain the value.
The concept of isolating the implementation of the methods and attributes within an object is known as encapsulation. Encapsulation is a powerful feature of object oriented systems because it separates the external part of an object (e.g. the part exposed to the objects user) from the internal part (e.g. the structure and implementation). Therefore, encapsulation permits changing the object implementation without affecting the interaction with other functions or objects as long as the interface does not change.
Just as there are many different concepts that define object oriented programming, there are also many different and diverse object oriented systems. Typically, the different object oriented systems are not compatible. However, integration of different object systems permits utilization of resources from several systems. For example, it is desirable to utilize, within a single integrated environment, object types and backend data sources from different systems. To accomplish this, conversion from one system to another is required.
One example of how systems differ is in methods of code reuse. For systems that implement inheritance, interfaces and implementations are incorporated by reference into derived types from parent or base types. The component object model (COM), defined as part of Microsoft's object linking and embedding (OLE) technology, does not use inheritance to make interfaces available to other objects. Instead, the COM specification defines use of containment and aggregation. In containment and aggregation, one object is part of another object. With containment, one object logically contains another object such that the outside or containing object creates the inside contained object without making any interface of the contained object directly available to client objects. In aggregation, the outside "aggregator" object exposes some or all of the inside "aggregatee" objects interfaces to the client object. As illustrated in the above example, different object oriented systems use different techniques for code reuse (e.g. inheritance, containment, and aggregation). Consequently, to successfully integrate different object oriented systems such as C++ and COM, the target system must be able to effectively handle the different abstract specifications of the different object oriented systems.
To solve the problem of different abstract specifications for different systems, systems, known as object middleware, utilize a cross product conversion approach. For this cross product approach, the object middleware converts directly from one system to another. For example, for an environment that attempts to integrate four systems, twelve conversions, three for each system, are required to completely integrate all four systems. If an additional system is introduced in the environment, eight more conversions are required to integrate the single additional system. As illustrated by this example, the cross product solution becomes exponentially more complex and difficult to implement as more object oriented systems are integrated into a single environment. Consequently, it is desirable to integrate different object oriented systems into a single system without providing a conversion mechanism between each pair of systems being integrated.
The least common denominator approach is another prior art technique used to implement object middleware. Using the least common denominator approach, the object middleware implements only the features common to all systems being integrated. For example, to integrate OLE objects and common object request broker architecture (CORBA) objects with a relational database as a backend data source, only those features supported by both CORBA and OLE can be used to access the relational database. Although the least common denominator approach provides a more straightforward implementation than the cross product approach, it does so at the expense of sacrificing functionality. Consequently, it is desirable to provide an integrated object oriented environment that does not require a conversion between each foreign object or data source system and that does not result in a subset of features through use of the least common denominator approach.
Object oriented systems utilize databases. For example, an object oriented software system uses databases to store instances of objects so that the objects "persist" in the database. Typically, the different data sources are not directly compatible in that each data source has specific requirements for executing transactions. Thus, an object oriented system must specifically interface with every different data source used in the system. Furthermore, in an object oriented system that integrates several different object systems (e.g. an object oriented system that implements foreign objects), each object system must conduct transactions specifically for the target data source.
One type of database used in software systems is a relational database. In general, a relational database stores information in the form of tables. Typically, relational databases include software that permit a user, through a query language, to visualize different portions and combinations of these tables. Object oriented software systems, which include encapsulated data and methods, do not have a direct counterpart with the relational model. For example, an object may include several attributes, specified by the class type, that define the state of the object at a particular time. To store the attributes of an object, an object oriented concept, in a relational database, a mapping of the attributes of the object to columns and rows in one or more tables is required.
Some prior art systems contain interfaces to generically access a data source, such as a relational database. For example, the Open Database Connectivity (ODBC) specification sets forth a standard interface to access databases. These standard interfaces provide uniform access to a database so that the object oriented system is not required to retain knowledge of the particular aspects necessary to perform transactions in every data source used in the system. Although such a standard interface simplifies access to data sources, the standard interfaces still require the data source client, such as an applications program operating in the object oriented system, to have a notion of the relational model (e.g. tables, columns and rows). For example, the standard interface may provide a standard access that obtains a particular row in a relational table. However, the client in the object oriented system must utilize the relational database in terms of columns and rows. Consequently, this prior art interface is a data access mechanism to integrate data from data sources into an object oriented system for manipulation.
Clients of a database issue querys statements, to extract information from the database. Query languages, such as the standard query language (SQL), are supported by databases to execute querys. However, SQL includes a number of dialects. Furthermore, some databases support some features specified in a query while others do not. As discussed above, a system may have multiple databases and utilize a standard interface, such as the ODBC interface, to access the databases. In such prior art systems, a client of a database is required to construct a SQL statement appropriate for the target database. Therefore, if there are multiple databases, then a single client user must maintain details on the particular dialect of the query language supported for that database. Thus, it is desirable to integrate data sources into an object oriented system without requiring the clients of the data sources to retain specific knowledge to execute transactions in one or more data sources.